Systems and methods for tracking, monitoring, and standardizing molecular and diagnostic testing products and services

ABSTRACT

The present disclosure relates to systems and methods for tracking, monitoring, and standardizing molecular and diagnostic testing products and services. A claim for payment, corresponding to a testing product or service, may be received, and a de-identification may be performed on the claim to remove personal identifiers from the claim to create a de-identified claim file. From the de-identified claim file, a unified representation of the claim may be created to form a structured payment claim object. The claim object may be matched to a specific testing product and/or a bin.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of and claims benefit of U.S. patentapplication Ser. No. 15/670,380, filed Aug. 7, 2017, which claimspriority to and benefit of U.S. Provisional Application No. 62/476,447,filed Mar. 24, 2017. These above-mentioned U.S. Patent Applications arehereby incorporated by reference in their entireties as if fully setforth below.

BACKGROUND

The present disclosure generally relates to testing products andservices such as genetic testing products provided by hundreds or eventhousands of providers (e.g., laboratories) worldwide. Numerouslaboratories are producing an increasing number of genetic tests, andeach laboratory provides different information about their specifictests. As a result, laboratories, hospitals, clinicians, and payers haveno consistent identifiers for products across the industry. Thisinconsistency and lack of transparency results in numerous issues. Forlaboratories, since it is often difficult to tell if a test is“medically necessary”, there is slow reimbursement from insurers. Forhospitals and healthcare providers, there are significant administrativeburdens and wasted time and effort attempting to determine anappropriate test, let alone the best test for the patient and thehospital. For patients, there are often long wait times and wastedco-pays as a result of mis-ordered tests. As a result, there is anefficiency loss resulting in higher health care costs and the increasedpossibility of fraud, waste, and abuse surrounding diagnostics. Inherentwithin the healthcare system, there is also a variety of mechanisms thatrequire information around testing products to be structured andapplied. It is with respect to these and other considerations that thevarious embodiments described below are presented.

SUMMARY

Some aspects of the present disclosure relate to systems, methods, andcomputer-readable storage media for tracking, monitoring, andstandardizing molecular and diagnostic testing products and services.

In one aspect, the present disclosure relates to a computer-implementedmethod. In one embodiment, the method includes receiving a claim forpayment corresponding to a testing product or service, and performingde-identification on the claim to remove personal identifiers from theclaim to create a de-identified claim file. The method also includescreating, from the de-identified claim file, a unified representation ofthe claim to form a structured payment claim object, and matching theclaim object to at least one of a specific testing product and a bin.Matching the claim object to a specific testing product includesidentifying a genetic testing unit (GTU) corresponding to a testingproduct that was ordered, using machine learning. The GTU is aconsistent identifier for tracking attributes of a specific testingproduct over time. Matching the claim object to a bin includes usingmachine learning, and the bin includes at least one categorized testingproduct. For a bin that includes two or more testing products, the twoor more testing products are similarly categorized.

In another aspect, the present disclosure relates to a system. In oneembodiment, the system includes one or more processors and a memorydevice coupled to the one or more processors. The memory device storesinstructions that, when executed by the one or more processors, causethe system to perform specific functions. The specific functionsperformed include receiving a claim for payment corresponding to atesting product or service, and performing de-identification on theclaim to remove personal identifiers from the claim to create ade-identified claim file. The specific functions performed also includecreating, from the de-identified claim file, a unified representation ofthe claim to form a structured payment claim object, and matching theclaim object to at least one of a specific testing product and a bin.Matching the claim object to a specific testing product includesidentifying a genetic testing unit (GTU) corresponding to a testingproduct that was ordered, using machine learning. The GTU is aconsistent identifier for tracking attributes of a specific testingproduct over time. Matching the claim object to a bin includes usingmachine learning, wherein the bin includes at least one categorizedtesting product. For a bin that includes two or more testing products,the two or more testing products are similarly categorized.

In yet another aspect, the present disclosure relates to anon-transitory computer-readable medium storing instructions that, whenexecuted by one or more processors, cause one or more computing devicesto perform functions that include: receiving a claim for paymentcorresponding to a testing product or service; performingde-identification on the claim to remove personal identifiers from theclaim to create a de-identified claim file; creating, from thede-identified claim file, a unified representation of the claim to forma structured payment claim object; and matching the claim object to atleast one of a specific testing product and a bin. Matching the claimobject to a specific testing product includes identifying a genetictesting unit (GTU) corresponding to a testing product that was ordered,using machine learning. The GTU is a consistent identifier for trackingattributes of a specific testing product over time. Matching the claimobject to a bin includes using machine learning, and the bin includes atleast one categorized testing product. For a bin that includes two ormore testing products, the two or more testing products are similarlycategorized.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the accompanying drawings, which are notnecessarily drawn to scale. The patent or application file contains atleast one drawing executed in color. Copies of this patent or patentapplication publication with color drawing(s) will be provided by theOffice upon request and payment of the necessary fee.

FIG. 1 is a diagram of a system and processes for performing certainaspects of tracking, monitoring, and standardizing molecular anddiagnostic testing products and services in accordance with someembodiments of the present disclosure.

FIGS. 2A and 2B are screen shots illustrating various aspects relatingto “Diff” associated with testing products, in accordance with someembodiments of the present disclosure.

FIGS. 3A-3D are screen shots illustrating various aspects relating to adatabase “squid” interface in accordance with some embodiments of thepresent disclosure.

FIG. 4 illustrates a system and process for matching a claim to aproduct and/or Bin, in accordance with some embodiments of the presentdisclosure.

FIGS. 5A and 5B are screen shots illustrating various aspects of expertreview in accordance with some embodiments of the present disclosure.

FIG. 6 is a diagram of a system for machine learning capable ofimplementing one or more embodiments.

FIG. 7 is diagram illustrating a computer hardware architecture for acomputing system capable of implementing one or more embodiments.

DETAILED DESCRIPTION

The following detailed description is directed to systems, methods, andcomputer-readable media for tracking, monitoring, and standardizingmolecular testing products and services.

Although example embodiments of the present disclosure are explained indetail, it is to be understood that other embodiments are contemplated.Accordingly, it is not intended that the present disclosure be limitedin its scope to the details of construction and arrangement ofcomponents set forth in the following description or illustrated in thedrawings. The present disclosure is capable of other embodiments and ofbeing practiced or carried out in various ways.

It must also be noted that, as used in the specification and theappended claims, the singular forms “a,” “an” and “the” include pluralreferents unless the context clearly dictates otherwise. Moreover,titles or subtitles may be used in this specification for theconvenience of a reader, which shall have no influence on the scope ofthe present disclosure.

By “comprising” or “containing” or “including” is meant that at leastthe named compound, element, particle, or method step is present in thecomposition or article or method, but does not exclude the presence ofother compounds, materials, particles, method steps, even if the othersuch compounds, material, particles, method steps have the same functionas what is named.

In describing example embodiments, terminology will be resorted to forthe sake of clarity. It is intended that each term contemplates itsbroadest meaning as understood by those skilled in the art and includesall technical equivalents that operate in a similar manner to accomplisha similar purpose. In describing embodiments, terminology related tolaboratory products can be used interchangeably. For example, genetictesting products, laboratory testing products, testing products, or thelike do not necessarily indicate different products/tests/etc.

It is to be understood that the mention of one or more steps of a methoddoes not preclude the presence of additional method steps or interveningmethod steps between those steps expressly identified. Steps of a methodmay be performed in a different order than those described herein.Similarly, it is also to be understood that the mention of one or morecomponents in a device or system does not preclude the presence ofadditional components or intervening components between those componentsexpressly identified.

In the following detailed description, references are made to theaccompanying drawings that form a part hereof and that show, by way ofillustration, specific embodiments or examples. In referring to thedrawings, like numerals represent like elements throughout the severalfigures.

In some embodiments, supervised and/or unsupervised machine learning canbe used. For example, when a specific genetic test is changed by alaboratory or test provider (e.g., a change in the scope of targetgenes), machine learning can be used to improve the efficacy ofrematching that test with its associated product and “Bin”, allowing thesystem to learn to better identify the product and/or bin based onunderlying patterns or features. A Bin as described herein may also bereferred to as a category.

Examples of machine learning processes and algorithms that may beutilized in performing certain aspects of the present disclosureinclude, but are not limited to, random force, support vector machines(SVM), random forest, neural networks, nearest-neighbor, naive Bayes,AdaBoost, QDA, decision trees, Gaussian processes, k-means, DBSCAN, andaffinity propagation.

Now referring to the system and processes (collectively labeled 100)illustrated in FIG. 1, according to some embodiments, a scraper 104 suchas a web scraper can be used to obtain data from laboratory and testingcompany websites 102 which contain information regarding testingproducts and/or services such as genetic testing products and services.In some embodiments, the data is in HTML and can then be stored as rawHTML in a cache 106. The scraper 104 may be an autonomous agent, forexample, and may be scheduled to scrape HTML or desired data from thevarious websites according to a schedule that may be customized for therespective sites, or otherwise run periodically to ensure thatup-to-date product and service information is obtained.

An extractor/standardizer 108 (hereinafter generally referred to as anextractor) can automatically pull data from the cache 106, such as theraw HTML data, and produce structured data. The structured data may beformed into various standardized fields relating to the testing productsand services, for charts and/or tables to be displayed to andmanipulated by a user, as will be later described with reference to, forinstance, embodiments relating to a database “squid” 116 and “Diff” 112.In some embodiments, the structured data may be a JSON object. Theextractor can be a rules-based data extraction tool (e.g., usingjavascript-based rules). In some embodiments, the standardized fieldsproduced by the extractor represent specific information about thetesting products. The testing product-specific information can be usedto analyze and sort the specific testing products. For example,standardized fields can include target gene(s), target analyte(s),testing technique, testing methodology, specific diseases, and/orspecific conditions, as will be further described below and shown inadditional Figures.

In some embodiments, a database (not shown) contains information used tostandardize information about individual laboratory companies. Thisincludes, or may include, information relevant to the location of thelaboratory, certifications, location, contact information, NationalProvider Identifiers (NPIs), Employer Identification Numbers (EINs),personnel, and other relevant information used to determine andstandardize a particular laboratory business entity as it exists. Insome embodiments, this information may be used by a variety of differentcomponents of this process such as 108 (FIG. 1) and 410 (FIG. 4).

In some embodiments, the extractor 108 can be used for, or in connectionwith, processes for Genetic Testing Unit (GTU) assignment. According tosome embodiments, testing products can be assigned a GTU. One of themany challenges for laboratories, hospitals, clinicians, and payers isthat there are no consistent identifiers for products across theindustry. GTUs can allow for versioning and tracking individual testingproducts through time, i.e., GTUs can be used to track a specificproduct as it evolves over time. A GTU is based on the concept of anorderable unit and can be standardized down to the specific methodologyof that orderable unit. As products evolve, the GTU is designed to takeinto consideration these various factors. It can be versioned, traceablethrough time, and relatable to specific marketing material specified ona laboratory's website. Thus, it is an individual record of the mostspecific type of actionable testing within the marketplace. GTUs canalso be designed to be able to translate between various identifiersused within the healthcare system. Currently, products, and thus GTUs,can have associated CPT codes that are specified by the laboratorieswith these products. UDIs and Z-codes can be associated as necessary. AGTU can be stored in a database as a GUID and versioned using the ISO8601 standard. The GTU and its version is a unique representation of atest's attributes, which can included its Bin. In some embodiments, theversion (timestamp) is updated when any data associated with the testchanges. Minor changes, such as description changes, and major changes,like targets or the Bin changing, can all constitute version changes.With each version of a GTU, all of the product attributes can be storedalong with that specific version.

As an example, if a product had its description changed by itslaboratory, the change would be captured in its GTU, and the previousdescription would still be available. Thus, a more complete picture ofthe specific product becomes available to interested parties. GTUs cancontain extensive information about their products, reflected in variousfields. For example, GTUs can contain information about the product'sCurrent Procedural Terminology (CPT) Code™, International Classificationof Disease, Nth Revision, Clinical Modification (ICD9 or ICD9CM, orICD10) Code, Unique Device Identification (UDI) Code, McKesson Z-Code™Identifier, test code, Bin information, tax information, NPI code,version or timestamp, description, target gene, list price, otherpricing data, time-to-results, laboratory code, the laboratory'sinternal test code, and other related data and information.

In some embodiments, a change to the test code for a product willtrigger a disassociation of a product with its GTU. In other words, ifeverything about a product were to change, but the test code remainedthe same, the GTU value would stay the same and the version would beincremented to the current timestamp. In some embodiments, anomalydetection can be performed, whereby a reconciliation event may occur ifcertain conditions are met (e.g., % of targets changing). In someembodiments, GTUs can be managed via the “Diff” using a test collectormodule. Expert curators (human users) can be alerted to changes in atest via the Diff user interface.

By way of example and not limitation, the scraper 104, extractor 108,test collector 110, Diff 112, and disorder matching 114, and any othercomponents for performing their respective functions, can reside inexecutable program modules (e.g., program modules 714 in FIG. 7) orother software constructs, or in dedicated programmed hardwarecomponents. These and other functional components of the embodimentsdescribed herein may be stored in memory devices (e.g., memory 704 ormass storage 712) and executable by processors (e.g., processing unit702) of one or more computers, such as the computer 700 shown in FIG. 7.The cache 106 and/or database squid 116 can be implemented through oneor more storage devices, such as in local electronic data storagedevices (e.g., data store 716) or external electronic data storagedevices such as remote databases. Although Bins and Binning will bedescribed in further detail below, as a brief upfront discussion, whenusing the test collector in accordance with some embodiments, everyproduct coming through the Diff that is added or modified that has beenun-binned (targets/techniques change) can be checked to ensure that theGTU and bin association are accurate. GTU data can be stored with theproducts in the “squid”, as will be described in further detail belowand shown in FIGS. 3A-3D. In some embodiments, all versions of a productcan be stored in the squid with a dropdown in a graphical user interfaceto access the data at specific points in time. Deprecated products maybe stored in the squid as well, and can be clearly marked as deprecated.“Deprecated products” refer to products that are no longer available forsale on the market, but which are stored historically in variousmatching processes because they are of historical use.

According to some embodiments, GTUs are assigned automatically to newproducts. As mentioned in some detail above, in some embodiments, theassignment is based primarily on the product's test code. GTU assignmentcan be reviewed manually. Automatic assignment, automatic review, ormanual review can result in reassignment of the product to an existingGTU, or assignment to a new GTU. In some embodiments, the GTU reviewprocess is managed using a Diff process, as will be described furtherbelow and with reference to FIGS. 2A and 2B. In some embodiments, manualreview of GTUs is completed in the Diff user interface.

In some embodiments, a GTU is reviewed automatically by an algorithmwhen a product is changed by its offering laboratory. It may beautomatically determined, for example, whether a differentclassification is needed for the GTU, or if the product needs a new GTU.This process can be verified by a user. This user verification canprovide feedback to the system, which can incorporate the feedback intofuture determinations, enacting a machine learning process. In someembodiments, this process can take place in the Diff, test collectormodule, or both. In some embodiments, each GTU can be associated withits own JSON object.

In some embodiments, pricing data can be associated with a GTU through aprocess that may be referred to herein as price matching, which canassociate pricing data using an algorithm. In some embodiments, pricematching is accomplished using comma separate value (CSV) data,containing structured pricing information. This CSV data can come from,for example, price sheets provided by clients, including laboratories,hospitals, and other testing providers. In certain embodiments, thisprocess can enable a user to find the best price for a desired result,for example, by allowing the user to sort testing products by price andprovider. Price matching can be reviewed automatically. In someembodiments, machine learning can be incorporated to improve theresults.

In some embodiments, information relating to the clinical disorders canbe associated with a GTU through a process that may be referred toherein as disorder matching (see e.g., “Disorder matching” 114 in FIG.1), which can associate a standardized disorder nomenclature with a GTU.In some embodiments, several different databases may be reconciled intoa single graph database (e.g., ArangoDB) that allows standardizedterminology to be applied consistently across laboratories. In someembodiments, disorder matching is accomplished using associationsbetween disorder nomenclature used by laboratories, gene information,protein function information, including other data fields andstandardized disorder terminology in a graph database. In certainembodiments, this process can enable a user to identify appropriatestandardized disorder nomenclature for particular GTUs by traversing thegraph using an algorithm. Disorder matching can be reviewedautomatically. In some embodiments, machine learning can be incorporatedto improve the results.

In some embodiments, this information can be associated at a step afterthe “Diff” and GTU assignment. In some embodiments, this enables theassignment of current clinical nomenclature used to describe a diseasestate, which is subject to change, to a particular GTU during the timein which that GTU exists. Thus, once this current nomenclature entersthe Squid, it becomes preserved during the time of that GTU's use,thereby creating a record.

Referring again to FIG. 1, a test collector 110 can perform functionsthat include automatically assigning products to Bins. Classification ofproducts within a market can be complicated and based on a number ofextrinsic factors that are relevant to a purchaser's use. Classificationof genetic testing products can be especially challenging, given thevariety of products and specific applications available within themarket. Through the implementation of various embodiments describedherein, providing accurate classifications can allow market participantsto operate within a specific framework and understand more broadly wheretheir products compete. In accordance with some embodiments of thepresent disclosure, a “binning” structure can be used forclassifications.

A Bin as referred to herein can be considered a clinically comparableset of testing products that answer a set of clinically comparablequestions. In accordance with some embodiments, testing products can beorganized or sorted based on various factors or characteristics, such astest attributes. For example, laboratory testing products might be“binned” based on the specific gene(s) or analyte(s) they are targetedto detect. In some embodiments, a “target” factor relates to specificgenes or analytes that are detected by the methodology of the testingproduct. Other factors that may be used include the methodologies usedto obtain testing results, the specific disease or condition productsare designed to address, and/or the specific clinical scenarios that theproducts are designed to address. For example, in some embodiments, a“techniques” factor relates to specific methodology that is used withinthe tests to determine a result, and a “disorders” factor relates tospecific diseases/conditions/clinical scenarios the products aredesigned to address.

According to some embodiments, Bins can have their scope determined in away that allows testing products to be grouped effectively. Bin scopecan be based on the same or different factors or characteristics used toplace the laboratory testing products into Bins. For example, the scopeof a Bin may be adjusted to conform to a change in the target gene(s) oranalyte(s) a common or popular testing product is targeted towards. Thiscould happen, for example, if it was discovered that multiple genes werecommonly associated with the same medical condition, or, for example, ifit became known that an additional gene or analyte was typically seenassociated with a medical condition where that gene had not previouslybeen associated. Other examples of reasoning for Bin changes include achange in preferred methodology or technique associated with a specifictest generally and new or evolving preferences and trends amongst bothconsumers and medical care providers. Thus, Bins can be flexible andadaptable to changes in the market, for example the market forlaboratory testing products. Bins can be combined or expanded andchanged to suit the products on the market, for instance, such aschanges due to methodology or product changes within the market. In someembodiments, retroactive traceability is maintained. A historicalversion of every Bin can be made through time and the products containedwithin each bin can be maintained, thus providing a complete history ofbins and products.

In some embodiments, products are classified into a single Bin, howeverBins can contain many different, but similar products. This allowscomparisons across products within single bins. Bins can also containunique identifiers that are assigned on creation. Products can beinitially classified into Bins when they are identified new in themarket. In some embodiments, a Bin is automatically created by analgorithm when a new testing product requiring a new Bin is found. A newBin can be created using an algorithm and then verified by an expert. Asproducts change, their Bin status can be reviewed and a decision about anew classification may be made. The update can then be made to the Binassignment.

If a new testing product is found that does not require a new Bin, nonew Bin will be created, but instead the testing product will beautomatically placed into its proper Bin via an algorithm. This processcan be verified by a user. This user verification can provide feedbackto the system, which can incorporate the feedback into futuredeterminations, enacting a machine learning process. Machine learningused in matching products to Bins, and refining product-to-Bin matches,in some embodiments, can utilize search and graph theory, for examplethrough the use of ElasticSearch. Other machine learning techniques thatmay be used include unsupervised clustering algorithms such as throughthe use of k-means, affinity propagation, and/or DBSCAN.

In some embodiments, a Bin is reviewed automatically by an algorithmwhen a product within the Bin is changed by its offering laboratory. Asystem can automatically determine, for example, whether a new scope orclassification is needed for the Bin, or if a new Bin needs to becreated. This process can be verified by a user. This user verificationcan provide feedback to the system, which can incorporate the feedbackinto future determinations, enacting a machine learning process. In someembodiments, these processes can take place in the test collector 110.

Data integrity of the overall system can be maintained through bothautomated and focused expert processes. The overall database oflaboratory testing products, Bins, GTUs, and associated information canbe routinely reviewed for errors and changes. In some embodiments,algorithms are used to routinely crawl through the overall datasetlooking for mis-classifications, mis-binning, necessary changes in thescope of Bins, and errors within the products themselves. In someembodiments, algorithms that may incorporate machine learning can beused to automatically make changes to correct the issues or “flag” theissue for review and correction by a user such as an expert reviewer.Periodic review of Bins can occur on a regular basis, for examplemonthly. Clinical, technical, and market experts can review Binsidentified by manual flagging or algorithms to sit outside the contextof defined marketplace parameters. These can then be resolved andchanges made. Referring to the screen shot of FIG. 3C, in someembodiments, this process takes place in the database “squid”, which canutilize an interface that allows users to drag and drop individualproducts between Bins. The squid interface can be configured to allow ananalyst (i.e., human user) to change the Bins in an on-the-fly manner toreorganize as desired and appropriate. For instance, in circumstanceswhere two Bins which are very similar were identified through a process,all of the products in the two Bins can be moved into a single Bin, andthen a GTU can be reassigned accordingly. In some embodiments, each Bincan be associated with its own JSON object.

In some embodiments, additional classification structures may be builton top of other data associated with GTUs, Bins, and other data that isstored or generated within the system. This data may be associated withits own JSON object and may utilize some of the components as outlinedin this system. Certain classifications can themselves be furtherclassifiable based on certain criteria such that a hierarchicalclassification structure/arrangement exists. There can thereby be ahierarchy of layers, which may include a domain layer in which a domaincan be considered a larger grouping of categories. These classificationsystems may contain information about the product's intended use,clinical classification, clinical scope, and other additional types ofclassification, for instance. The classifications can be according to,for example: clinical scope corresponding to clinical practice forparticular specialties or sub-specialties of medical usage, and/ormarket scope as it relates to, for instance, competition amongst a groupof laboratories in a particular market, health plans, or other relatedentities that would utilize the relevant information according to suchembodiments in the normal course of business.

FIGS. 2A and 2B are screen shots illustrating various aspects relatingto “Diff” associated with testing products, in accordance with exampleembodiments of the present disclosure. In particular, FIGS. 2A and 2Billustrate screen shots of a dashboard of a graphical user interfacetool showing various listed testing products by test code and name, aswell as corresponding fields of data for each testing product.“Diff”-related functionalities described herein with respect to certainembodiments can involve the identification of changes in productinformation over time, as reflected in changes in the information shownin the data fields. This can also include the removal or addition ofinformation in each of these fields. It also can include informationabout validation errors or errors in matching to a standardized term.

FIG. 2A illustrates a listing of testing products, organized in rowswith a test code and name in a left column and a corresponding set ofindicators for the various fields for each product, listed horizontallyacross the row. For example, one listed test product is listed by testcode “2440” and the name “Angelman/Prader-Willi Methylation Studies15q11-13”. In the corresponding right column, as noted by the commentbox and attached arrow inserted into the diagram, information haschanged for two particular fields. As shown, the fields are visuallyemphasized by highlighting them (see “TAL” and “TAH”). Another listedtest product has test code “2680” and the name “RET Gene Sequence”. Inthe right column, as shown there is a highlighted indicator “TAL”.

FIG. 2B shows the listed test product for test code 2440 mentionedabove, but in an expanded view which shows the fields and correspondingdetails. As illustrated in the expanded view (and as noted in thecomment box inserted into the diagram), there is an indication thatinformation for the field “turn_aroundlow” (abbreviated by “TAL” in theview of FIG. 2A) has changed to a value of 14 (in the view of FIG. 2B),and also an indication that information for the field “turn_around.high”(abbreviated by “TAH” in the view of FIG. 2A) has changed to a value of28 (in the view of FIG. 2B).

It should be noted that the comment box and attached arrow in FIG. 2A(“Notifications that a field has changed information for that product”)is intended for purposes of labeling elements of the illustratedembodiment of the present disclosure for convenience of the reader, anddoes not in itself constitute any substantive element of the embodimentshown. Similarly, the comment box in FIG. 2A (“Expanded view of thetesting product showing what has changed (in this case turn_around.highand turn_aroundlow”) is intended for noting aspects of the illustratedembodiment of the present disclosure for purposes of convenience of thereader, and does not in itself constitute any substantive element of theembodiment shown.

According to some embodiments, the entire database of information (e.g.,information regarding the laboratory testing products, their processedinformation, and the historical data associated with that information)can be maintained in a database squid 116 (FIG. 1). As shown in thescreen shots of FIGS. 3A-3D and further described below, the squid 116can provide contextual information for users making manual updates tothe information in the system, including updates to GTUs and Bins.

In some embodiments, the squid 116 is a database that can store andmaintain both a current record and backup record of all the informationregarding testing products. The backup can be a historical record whichcan be used in making determinations, for example, during the matchingprocesses or Diff process. In some embodiments, the squid 116 will allowaccess to the backup via a graphical user interface that comprises adropdown menu. Such a menu can allow for a user to access the backup andto select between various saved versions of the historical data of aspecific test product, or the information regarding testing products asa whole. Access to this information can allow the user to fullyunderstand the product and how it has evolved, facilitating a moreaccurate review of the product and facilitating a more accurate edit ofthe product, if necessary.

In some embodiments, the squid 116 interface allows a user to understandand identify detailed information about individual products andservices. In some embodiments, a user can examine these products ascurated within individual Bins or other groupings. Although someembodiments described herein and as shown in FIG. 1 show the squid andDiff as separate components, in other embodiments, the interface maycomprise a “collections” view, whereby different standardizationfunctions can be performed within the same interface, i.e. variousfunctions that in some embodiments are performed in a Diff interface anda separate squid interface can be performed using an integrated,consolidated interface view.

FIG. 3A shows a screen shot detailing characteristics and data fieldsabout individual testing products as shown in the squid interface. Asillustrated, individual testing products and their data fields aredetailed as individual rows in the table. FIG. 3B shows a screen shotdetailing a customization of the fields displayed for each product. Insome embodiments, this allows an individual user to customize the datafields within their view for the particular application. FIG. 3C shows ascreen shot detailing binning adjustments between products. In someembodiments, users may move individual products between Bins in order toadjust the composition of Bins for a variety of reasons. FIG. 3D shows ascreen shot detailing a specific data object relevant to an individualGTU or product. This allows a user to access the raw data object ifnecessary for their particular application. It should be noted that thecomment boxes and/or arrows in FIGS. 3A-3D are intended for purposes oflabeling elements and/or noting aspects of the illustrated embodiment ofthe present disclosure for purposes of convenience of the reader, and donot in themselves constitute any substantive elements of the embodimentsshown (see FIG. 3A, “Comprehensive view of all products contained withinan individual bin and the associated data with each product”; FIG. 3B,“Customization of individual data fields for each product”; FIG. 3C,“Binning can be adjusted within the squid interface by dragging anddropping individual products between bins”, and attached two arrows; andFIG. 3D, “Detail of specific data for an individual GTU/Product”, andattached arrow).

FIG. 4 illustrates a claims matching process 400 for matching a claim toa product and/or Bin, in accordance with some embodiments of the presentdisclosure. Matching of a claim object with a product and/or Bin canallow the user to understand the relationship between the original claim(that was used to create a claim object) and the payment for the desiredtesting product; it can be considered a reconciliation between a billingsystem nomenclature and the products or services on the market. This ishelpful because of the increasingly unmanageable number of uniquegenetic testing and other testing products aimed at personalizedmedicine. That is, as genetic testing has become increasingly common andpopular, the number of tests has grown to over 65,000, with an averageof ten new tests entering the market daily. All of these tests representover 14,000 distinct, clinically relevant categories. This rapid growthhas made it increasingly difficult to accurately manage ordering,billing, and reimbursement of the tests.

An incoming claim is used to create a claim object. The claim object canbe created by associating a testing product's information into the claimobject. In some embodiments, the associated testing product informationis structured to allow for an algorithm to match the structured data toa testing product or GTU. As shown in FIG. 4, a raw claim file 402, suchas an electronic medical claim in electronic form, can be put throughde-identification 404 to remove all personal identifiers from the claimfile, thereby creating a de-identified claim file 406. The de-identifiedclaim file 406 can then be used to create the claim object at 408.

Now referring to building a claim object (see 408), in some embodiments,the claim object can include a unique claim identifier for each claimand provider identifiers, which essentially can serve to indicate whatproduct or service was ordered and represented by a particular claim.The provider identifiers can include Tax ID, NPI, and provider name,together creating a provider identification. The claim objectcan becreated by incorporating this information, along with CPT Codes,ICD9/ICD10 Code, service unit(s), modifier codes, and other relatedinformation associated with the individual claim in a structured format.A CPT signature can be created from the billing code (HCPCS, CPT code,Z-code) and service units, to create a data object representing, forinstance, how many of each billing code was billed for a particularservice. In some embodiments, the structuring of this information canoccur through an algorithm that is designed to create a unified andconsistent representation of an individual claim from across multipledisparate health plan claim accounting systems. In some embodiments, thealgorithm can be enhanced using machine learning processes, such asthose as will be described in further detail below.

In some embodiments, an algorithm may access an electronic databasecontaining associations of information related to a testing company or alaboratory (e.g., National Provider Identification (NPI) number, taxinformation, or other company/laboratory specific information). Thealgorithm can then associate a specific testing product with a specifictesting company and/or laboratory using the information available to it(see 410). In some embodiments, this is a standardized identifier for aparticular laboratory entity that is maintained through the systemdescribed in 108. In some embodiments, this process can be checkedmanually. In some embodiments, the algorithm can be enhanced using oneor more machine learning processes. A claim object can then be used tofacilitate product matching 412 a or Bin matching 412 b (collectively412). The product matching process 412 a can automatically search anindex and associate the claim object with the product, which can alreadybe associated with a Bin. The product can be previously associated witha Bin in the test collector module (see, e.g. 110 in FIG. 1), asoutlined above. In matching to a product, the exact GTU that was orderedcan be identified, using a combination of machine learning and search,and a particular Bin can then be derived. In the product matchingprocess 412 a, in some embodiments, product information from the squid(see 414) or a data representation in the squid can also be utilized. Insome embodiments, if the structured testing product information cannotbe matched to a specific product by the algorithm, then the claim objectis matched to a Bin (see 412 b). This may happen, for example, if thetesting company or the laboratory completing the test is not clear,i.e., information is too vague or there is an anomaly. In someembodiments, one or more machine learning enhanced algorithms can beused to enhance the product matching, Bin matching, or both. In someembodiments, this process can be reviewed manually.

By way of example and not limitation, the components illustrated byblocks corresponding to de-identification 404, build claim object 408,matching laborary provider to standard identifier 410, product matching412 a and/or bin matching 412 b, and expert review 416, and any otherfunctional components for performing their respective functions, canreside in executable program modules (e.g., program modules 714 in FIG.7) or other software constructs, or in dedicated programmed hardwarecomponents. These and other functional components of the embodimentsdescribed herein may be stored in memory devices (e.g., memory 704 ormass storage 712) and executable by processors (e.g., processing unit702) of one or more computers, such as the computer 700 shown in FIG. 7.The database squid 116 and analytics database 418 can be implementedthrough one or more storage devices, such as in local electronic datastorage devices (e.g., data store 716) or external electronic datastorage devices such as remote databases.

Various machine learning processes/algorithms may be utilized forimplementing some aspects of the present disclosure. For example, insome embodiments, product matching 412 a and/or Bin matching 412 b canbe performed by using a random forest algorithm, wherein a claim comesin, is matched to a product and/or Bin based on a training data set thathas been developed which creates a kind of random forest model, and theclaim is then run through the model. In some embodiments, a table ofmatches that may use signatures to products and/or bins can be built upover time, which can be built in SQL (structured query language). Thebuilt-up, known matches table can be used as a training data set forrunning machine learning algorithm(s) to perform matching of remaining,unmatched claims, for example by using a random forest model. As will berecognized by those skilled in the art, random forest techniques (alsoreferred to as random decision forests) relate to ensemble learningmethod which constructs a plurality of decision trees at training timeand outputs the class that is the mode of the classes/classification ormean prediction/regression of individual trees. In accordance with someembodiments, claims information can be run through a random forestapproach, and then identified accurate or otherwise desirable matchesthat are achieved can then be used for further training data sets insubsequent iterations of the respective machine learning model.Alternative approaches utilizing machine learning that may be utilizedinclude techniques that may use search algorithms of ElasticSearch.

For product matching 412 a, a search interface can be used. It should beappreciated that many different types of machine learning algorithms canbe utilized. As described in some detail above, in product matching, aclaim object is analyzed to look at the CPT signature, look at theservice units and the ICD 9/10 codes, and determine what product is mostlikely represented by a signature. It also can incorporate laboratoryinformation indicating who has performed a service. Expert review steps(see expert review 416) can be used to either validate or makecorrections, and all the metadata can go back into training thosealgorithms.

In some embodiments, the results of the product matching 412 a or Binmatching 412 b processes can then be reviewed by a user in a processthat, for some embodiments, is referred to herein as “expert review”416, as shown in FIGS. 5A and 5B and described in further detail below.Data resulting from expert review can be saved and used to refinealgorithms in a feedback loop, i.e., the algorithm can be given feedbackto optimize its association of the claim object, thus enacting a machinelearning process.

In some embodiments, in expert review 416, the individual product and/orbin matches can be reviewed by an expert user to refine and revisematches. In some embodiments, an individual user can utilize aninterface designed to alter and correct these matches, as shown in FIGS.5A and 5B. The matched claim information can then be stored in a broaderanalytics database 418, and joined back with other information containedwithin the identified claim file to provide a more comprehensive versionof the actual claim.

FIGS. 5A and 5B are screen shots illustrating an interface for, andvarious aspects of, expert review in accordance with example embodimentsof the present disclosure. In some embodiments, individual productmatches can be reviewed by an expert user to refine and revise productmatches. In some embodiments, an individual user can utilize aninterface designed to alter and correct these matches. FIG. 5A showsde-identified claim objects that, in some embodiments, have beenpreviously associated with an individual testing product. In someembodiments, a variety of filtering mechanisms enable the user to filterand identify the specific claims they are currently manipulating in theinterface. FIG. 5B shows a selected set of claim objects, with theirassociated product information that have been identified forre-assignment. In some embodiments, a search interface allows the userto access and filter product information from the squid (see, e.g., 116in FIG. 1) to assign a GTU to the individual claim. It should be notedthat the comment boxes and/or arrows in FIGS. 5A and 5B are intended forlabeling elements and/or noting aspects of the illustrated embodiment ofthe present disclosure for purposes of convenience of the reader, and donot in themselves constitute any substantive elements of the embodimentsshown (see FIG. 5A, “Claims and their assigned products” and “Variety offiltering mechanisms” and attached arrow; and FIG. 5B “Selected claimsfor assignment or re-assignment” and attached arrows, and “Searchinterface to find the right product and make the assignment” andattached arrow).

In some embodiments, an algorithm may identify and create claim objectsfrom across multiple individual claims. In some embodiments, thisprocess can then be reviewed by a user. In some embodiments, thealgorithm can be given feedback to optimize its association of the claimobject. In some embodiments, an algorithm may associate a single claimwith a combination of multiple GTUs to create multiple claim objects. Insome embodiments, this process can then be reviewed by a user. In someembodiments, the algorithm can be given feedback to optimize itsassociation of the claim object.

According to some embodiments, reports can be generated based oninquiries. For example, a report could be generated that providesinformation about all of the testing products that will accomplish thedesired purpose of the test. This could be, for example, testing of aspecific gene. These tests could be sorted, for example, by price, thusenabling the report recipient to make a more educated decision inpurchasing or using testing products. For example, the reports could betailored to examine specific testing companies or laboratories in aneffort to combat fraud or eliminate wasteful spending. In someembodiments, various reports can be generated from data in the analyticsdatabase, and there can be a user interface provided for a client toaccess and interact with the analytics database.

According to some embodiments, an interface can be developed and appliedto generate reports based on inquiries. In some embodiments, thesereports can be delivered in a flexible manner that allows a user towrite and define their own inquiries into the specific datasets. Forexample, multiple end users can access a variety of reports withincustom dashboards.

FIG. 6 is a diagram illustrating architecture of an exemplary system 600for machine learning in which one or more example embodiments describedherein may be implemented. For example, one or more components andaspects of the system 600 may be used in the product and/or Bin matchingprocesses and/or expert review as described above in variousembodiments. Under supervised learning, human users may provide examplesof changes and their corresponding desired result. For example, when aspecific genetic test is changed by a laboratory or test provider (e.g.,a change in the scope of target genes), machine learning can be used toimprove the efficacy of re-matching that test with its associatedproduct and Bin.

As shown, the system 600 includes a user computer 604 operated by a user602. The user computer 604 can include some or all of the components ofthe computer 700 shown in FIG. 7 and described in further detail below.A user interface such as a graphical user interface executing on thecomputer 604 may be configured to receive user input 605. By interactingwith the user interface of the user computer 604, the user 602 mayperform, via a model training client 606, functions associated withmodel training in machine learning, according to some embodimentsdescribed herein. The user interface may provide one or morefunctionalities associated with the user interfaces shown in FIGS. 2A,2B, 3A-3D, 5A, and 5B.

A base model (see model 610) may be used to make first “predictions” ona first set of data, for example a decision that a particular data itemcorresponds to and should be matched to a particular product or service,or that a particular claim should be matched to a particular product orBin. A user 602 such as an analyst may then correct incorrect resultsfrom the first predictions. The corrected data may then be used to train(see “training 608”) to produce a new model (e.g., enhanced, improved,further trained model of model 610) based on the corrections made to thefirst data. This new model may then be used to make predictions onsecond data, and so on accordingly. This prediction, correction, andtraining process may progressively improve a model as additional itemsare processed. In some embodiments, one or more functions of thetraining, prediction, and feedback processes may be unsupervised, forexample they may be performed autonomously by computer without userintervention.

As discussed above with respect to various implementations, variousmachine learning processes/algorithms may be utilized for implementingaspects of the present disclosure. For example, in some embodiments,product matching and/or Bin matching (see, e.g., FIG. 4) can beperformed by using a random forest algorithm, wherein a claim comes in,is matched to a product and/or Bin based on a training data set that hasbeen developed which creates a kind of random forest model, and theclaim is then run through the model. In some embodiments, a table ofmatches that may use signatures to products and/or bins can be built upover time, which can be built in SQL (structured query language). Thebuilt-up, known matches table can be used as a training data set forrunning machine learning algorithm(s) to perform matching of remaining,unmatched claims, for example by using a random forest model. Inaccordance with some embodiments, claims information can be run througha random forest approach, and then identified accurate or otherwisedesirable matches that are achieved can then be used for furthertraining data sets in subsequent iterations of the respective machinelearning model.

Alternative approaches utilizing machine learning that may be utilizedinclude techniques that may use search algorithms of ElasticSearch.Machine learning used in matching products to bins, and refiningproduct-to-bin matches, in some embodiments, can utilize search andgraph theory, for example through the use of ElasticSearch. Othermachine learning techniques that may be used include unsupervisedclustering algorithms such as through the use of k-means, affinitypropagation, and/or DBSCAN. In accordance with some embodiments, one ormore aspects of neural networks can be utilized, for example to take andweight different diagnosis codes, procedure codes, and laboratory namesand allow for the exploration around more of the parameter space arounddiagnosis codes.

FIG. 7 is a computer architecture diagram showing a general computingsystem capable of implementing one or more embodiments of the presentdisclosure described herein. A computer 700 may be configured to performone or more functions associated with embodiments illustrated in one ormore of FIGS. 1-6. It should be appreciated that the computer 700 may beimplemented within a single computing device or a computing systemformed with multiple connected computing devices. For example, thecomputer 700 may be configured for a server computer, desktop computer,laptop computer, or mobile computing device such as a smartphone ortablet computer, or the computer 700 may be configured to performvarious distributed computing tasks, which may distribute processingand/or storage resources among the multiple devices.

As shown, the computer 700 includes a processing unit 702, a systemmemory 704, and a system bus 706 that couples the memory 704 to theprocessing unit 702. The computer 700 further includes a mass storagedevice 712 for storing program modules. The program modules 714 mayinclude modules executable to perform one or more functions associatedwith embodiments illustrated in one or more of FIGS. 1-6. The massstorage device 712 further includes a data store 716.

The mass storage device 712 is connected to the processing unit 702through a mass storage controller (not shown) connected to the systembus 706. The mass storage device 712 and its associated computer storagemedia provide non-volatile storage for the computer 700. By way ofexample, and not limitation, computer-readable storage media (alsoreferred to herein as “computer-readable storage medium” or“computer-storage media” or “computer-storage medium”) may includevolatile and non-volatile, removable and non-removable media implementedin any method or technology for storage of information such ascomputer-storage instructions, data structures, program modules, orother data. For example, computer-readable storage media includes, butis not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solidstate memory technology, CD-ROM, digital versatile disks (“DVD”),HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetictape, magnetic disk storage or other magnetic storage devices, or anyother medium which can be used to store the desired information andwhich can be accessed by the computer 700. Computer-readable storagemedia as described herein does not include transitory signals.

According to various embodiments, the computer 700 may operate in anetworked environment using connections to other local or remotecomputers through a network 718 via a network interface unit 710connected to the system bus 706. The network interface unit 710 mayfacilitate connection of the computing device inputs and outputs to oneor more suitable networks and/or connections such as a local areanetwork (LAN), a wide area network (WAN), the Internet, a cellularnetwork, a radio frequency network, a Bluetooth-enabled network, a Wi-Fienabled network, a satellite-based network, or other wired and/orwireless networks for communication with external devices and/orsystems.

The computer 700 may also include an input/output controller 708 forreceiving and processing input from a number of input devices. Inputdevices may include, but are not limited to, keyboards, mice, stylus,touchscreens, microphones, audio capturing devices, or image/videocapturing devices. An end user may utilize such input devices tointeract with a user interface, for example a graphical user interfaceon one or more display devices (e.g., computer screens), for managingvarious functions performed by the computer 700, and the input/outputcontroller 708 may be configured to manage output to one or more displaydevices for visually representing data.

The system bus 706 may enable the processing unit 702 to read codeand/or data to/from the mass storage device 712 or othercomputer-storage media. The computer-storage media may representapparatus in the form of storage elements that are implemented using anysuitable technology, including but not limited to semiconductors,magnetic materials, optics, or the like. The program modules 714 mayinclude software instructions that, when loaded into the processing unit702 and executed, cause the computer 700 to provide functions associatedwith embodiments illustrated in FIGS. 1-6. The program modules 714 mayalso provide various tools or techniques by which the computer 700 mayparticipate within the overall systems or operating environments usingthe components, flows, and data structures discussed throughout thisdescription. In general, the program module 714 may, when loaded intothe processing unit 702 and executed, transform the processing unit 702and the overall computer 700 from a general-purpose computing systeminto a special-purpose computing system.

The processing unit 702 may be constructed from any number oftransistors or other discrete circuit elements, which may individuallyor collectively assume any number of states. More specifically, theprocessing unit 702 may operate as a finite-state machine, in responseto executable instructions contained within the program modules 714.These computer-executable instructions may transform the processing unit702 by specifying how the processing unit 702 transitions betweenstates, thereby transforming the transistors or other discrete hardwareelements constituting the processing unit 702. Encoding the programmodules 714 may also transform the physical structure of thecomputer-readable storage media. The specific transformation of physicalstructure may depend on various factors, in different implementations ofthis description. Examples of such factors may include, but are notlimited to: the technology used to implement the computer-readablestorage media, whether the computer-readable storage media arecharacterized as primary or secondary storage, and the like. Forexample, if the computer-readable storage media are implemented assemiconductor-based memory, the program modules 714 may transform thephysical state of the semiconductor memory, when the software is encodedtherein. For example, the program modules 714 may transform the state oftransistors, capacitors, or other discrete circuit elements constitutingthe semiconductor memory.

As another example, the computer-storage media may be implemented usingmagnetic or optical technology. In such implementations, the programmodules 714 may transform the physical state of magnetic or opticalmedia, when the software is encoded therein. These transformations mayinclude altering the magnetic characteristics of particular locationswithin given magnetic media. These transformations may also includealtering the physical features or characteristics of particularlocations within given optical media, to change the opticalcharacteristics of those locations. Other transformations of physicalmedia are possible without departing from the scope of the presentdisclosure.

Although some embodiments described herein have been described inlanguage specific to computer structural features, methodological actsand by computer readable media, it is to be understood that thedisclosure defined in the appended claims is not necessarily limited tothe specific structures, acts or media described. Therefore, thespecific structural features, acts and mediums are disclosed asexemplary embodiments implementing the claimed disclosure.

This written description uses examples to disclose certainimplementations of the disclosed technology, including the best mode,and also to enable any person of ordinary skill to practice certainimplementations of the disclosed technology, including making and usingany devices or systems and performing any incorporated methods. Thepatentable scope of certain implementations of the disclosed technologyis defined in the appended claims and their equivalents, and may includeother examples that occur to those of ordinary skill. Such otherexamples are intended to be within the scope of the claims if they havestructural elements that do not differ from the literal language of theclaims, or if they include equivalent structural elements withinsubstantial differences from the literal language of the claims.

What is claimed is:
 1. A computer-implemented method, comprising:receiving a claim for payment corresponding to a genetic testingproduct; performing de-identification on the claim for payment to removepersonal identifiers from the claim for payment, to create ade-identified claim file; creating, from the de-identified claim file, aunified representation of the claim for payment, to form a structuredpayment claim object; matching the claim object to at least one of: (i)a specific genetic testing product; and (ii) a bin of a plurality ofbins for classification of the genetic testing product, wherein the bincomprises at least one categorized testing product and, for a bin thatcomprises two or more testing products, the two or more testing productsare similarly categorized; wherein: matching the claim object to aspecific testing product comprises identifying a genetic testing unit(GTU) corresponding to a testing product that was ordered and matchingthe claim object to the testing product based on the corresponding GTU,wherein the GTU is a consistent identifier representing, and fortracking of, a plurality of attributes of a specific testing productover time, wherein the plurality of attributes comprise at least one ofa test code, target gene, target analyte, bin, and description of thetesting product from the provider of the testing product, and whereinthe GTU for the testing product changes when at least one attribute ofthe plurality of attributes of the testing product changes, and matchingthe claim object to a bin comprises matching the claim object to a binfrom a plurality of different bins having different respectiveclassifications, wherein the scope of at least one of the plurality ofbins is adjustable relative to the scope of at least one other bin ofthe plurality of bins, and wherein the plurality of bins are combinableor expandable; and wherein at least one of matching the claim object toa specific testing product and matching the claim object to a bin isperformed at least in part using a machine learning model, trained basedon a training set comprising previously identified matches of claimobjects to testing products or bins.
 2. The method of claim 1, whereinidentifying the GTU corresponding to a testing product that was orderedfurther comprises using a user search interface.
 3. The method of claim1, wherein the claim object includes at least one billing code for aparticular testing product.
 4. The method of claim 1, wherein theunified representation of the claim is created from across a pluralityof types of health plan claim accounting systems.
 5. The method of claim1, wherein the structured payment claim object comprises a plurality offields, the plurality of fields comprising an indication of at least oneof: a target gene the testing product is designed to detect, a targetanalyte the testing product is designed to detect, a testing technique,a testing methodology, a specific disease, and a specific condition. 6.The method of claim 1, wherein the GTU for a particular testing productis storable in a plurality of versions over time, each versionindicating attributes of the testing product at a particular point intime.
 7. The method of claim 1, further comprising automaticallydetermining, in response to the change in at least one attribute,whether a different classification is needed for the GTU or a new GTU isneeded.
 8. The method of claim 1, wherein using the machine learning forthe matching of the claim object to the specific testing productcomprises training the machine learning model to improve matching of theclaim object to a testing product when at least one attribute of thetesting product is changed by a corresponding provider.
 9. The method ofclaim 1, wherein using the machine learning for matching the claimobject to a bin comprises training the machine learning model to improvematching of the claim object to a bin when at least one attribute of thetesting product is changed by a corresponding provider.
 10. The methodof claim 1, wherein at least one of the machine learning for matchingthe claim object to a specific testing product and the machine learningfor matching the claim object to a bin comprises using a random foresttechnique.
 11. The method of claim 1, wherein the classifications of thedifferent respective classifications of the plurality of different binsare further classifiable into a multiple layered arrangement ofclassifications according to at least one of clinical scope and marketscope associated with the testing product.
 12. The method of claim 1,further comprising versioning at least one of the plurality of bins totrack the contents of the at least one respective bin over time.
 13. Themethod of claim 1, further comprising automatically adjusting at leastone of the scope or size of at least one bin in response to determiningthat at least one testing product within the bin has been changed by itsrespective provider.
 14. The method of claim 1, further comprisingproviding, to an analytics database, data corresponding to matchedclaims for payment, from the matching of the claim object to the atleast one of the specific testing product and bin, and wherein theanalytics database is configured to receive a user inquiry and togenerate, in response to the user inquiry, a report providinginformation associated with testing products and categories.
 15. Themethod of claim 14, wherein the information provided in the reportcomprises information on at least one of unit pricing, testingmethodologies, and statistics on volume in the market for particularcategories.
 16. A system, comprising: one or more processors; and amemory device coupled to the one or more processors and storinginstructions that, when executed by the one or more processors, causethe system to perform functions that include: receiving a claim forpayment corresponding to a genetic testing product; performingde-identification on the claim for payment to remove personalidentifiers from the claim for payment, to create a de-identified claimfile; creating, from the de-identified claim file, a unifiedrepresentation of the claim for payment, to form a structured paymentclaim object; matching the claim object to at least one of: (i) aspecific testing product; and (ii) a bin of a plurality of bins forclassification of the genetic testing product, wherein the bin comprisesat least one categorized testing product and, for a bin that comprisestwo or more testing products, the two or more testing products aresimilarly categorized; wherein: matching the claim object to a specifictesting product comprises identifying a genetic testing unit (GTU)corresponding to a testing product that was ordered and matching theclaim object to the testing product based on the corresponding GTU,wherein the GTU is a consistent identifier representing, and fortracking of, a plurality of attributes of a specific testing productover time, wherein the plurality of attributes comprise at least one ofa test code, target gene, target analyte, bin, and description of thetesting product from the provider of the testing product, and whereinthe GTU for the testing product changes when at least one attribute ofthe plurality of attributes of the testing product changes, and matchingthe claim object to a bin comprises matching the claim object to a binfrom a plurality of different bins having different respectiveclassifications, wherein the scope of at least one of the plurality ofbins is adjustable relative to the scope of at least one other bin ofthe plurality of bins, and wherein the plurality of bins are combinableor expandable; and wherein at least one of matching the claim object toa specific testing product and matching the claim object to a bin isperformed at least in part using a machine learning model, trained basedon a training set comprising previously identified matches of claimobjects to testing products or bins.
 17. A non-transitorycomputer-readable medium storing instructions that, when executed by oneor more processors, cause one or more computing devices to performfunctions that comprise: receiving a claim for payment corresponding toa genetic testing product; performing de-identification on the claim forpayment to remove personal identifiers from the claim for payment, tocreate a de-identified claim file; creating, from the de-identifiedclaim file, a unified representation of the claim for payment, to form astructured payment claim object; matching the claim object to at leastone of: (i) a specific genetic testing product; and (ii) a bin of aplurality of bins for classification of the genetic testing product,wherein the bin comprises at least two categorized testing products and,for a bin that comprises two or more testing products, the two or moretesting products are similarly categorized; wherein: matching the claimobject to a specific testing product comprises identifying a genetictesting unit (GTU) corresponding to a testing product that was orderedand matching the claim object to the testing product based on thecorresponding GTU, wherein the GTU is a consistent identifierrepresenting, and for tracking a plurality of attributes of, a specifictesting product over time, wherein the plurality of attributes compriseat least one of a test code, target gene, target analyte, bin, anddescription of the testing product from the provider of the testingproduct, and wherein the GTU for the testing product changes when atleast one attribute of plurality of attributes of the testing productchanges, matching the claim object to a bin comprises matching the claimobject to a bin from a plurality of different bins having differentrespective classifications, wherein the scope of at least one of theplurality of bins is adjustable relative to the scope of at least oneother bin of the plurality of bins, and wherein the plurality of binsare combinable or expandable; and wherein at least one of matching theclaim object to a specific testing product and matching the claim objectto a bin is performed at least in part using a machine learning model,trained based on a training set comprising previously identified matchesof claim objects to testing products or bins.